Types of deployment

Important: This guide does not include any details about the Hosted by Quorum deployment of Planning Space (see Deployment infrastructure overview). The following information is only about deployment based on customer infrastructure.

Architectural design decisions for on-premises deployment mainly fall into server-side or client-side issues. The main elements of a Planning Space deployment are shown in the following diagram.


Schematic diagram of a Planning Space deployment. The elements shown in grey (SMTP Server, Application Provisioning servers) are optional. Client sites may be all local, or all remote, or a combination.

It is important to deploy Planning Space at the correct size initially, based on good estimates of initial and future capacity (that is, the number of server machines, and the CPU, RAM and disk resources allocated to each machine). Experience has shown that making changes in production deployments is typically a very slow and time-consuming process.

Server-side architecture

IPS server is deployed in a data center with the following resources:

  • one or more dedicated IPS Server machines (multiple machines are called a 'cluster');
  • a load balancer to interface with a cluster of IPS Server machines;
  • access to a Microsoft SQL Server service to provision and run databases;
  • a file share (Cluster Shared Temp folder) for temporary storage and inter-process communication;
  • (optional) access to an SMTP server to provide automated email-based communication with users;
  • (optional) application provisioning service (such as Citrix) for provisioning of Planning Space services to remote client machines;
  • a data center LAN to inter-connect all of the servers and the file share (latency between servers must be 1 ms or lower);
  • a firewall at the perimeter of the entire server deployment, to control external communication with client user sites.

The IPS server-side deployment is quite simple to implement, but careful planning is recommended to determine the initial processing and storage resources required, and the planned scaling of resources for future growth in usage.

When users' immediate processing requests exceed the system capacity, requests are automatically queued for later completion. A design trade-off for system capacity needs to be decided between delivering immediate responses to user's requests, and forcing users to wait for completion of their requests (or require them to use batch processing of jobs). The level of use of Planning Space applications tends to be strongly cyclical through the year (as it is tied to annual business planning cycles) and it may be desirable to design a Planning Space deployment so that some level of 'batch' processing is going to occur at peak usage periods, or alternatively to plan for the use of temporary 'burst' compute resources at peak periods.

As the use of Planning Space develops within a company, the volume of historical data grows and this means that the amounts of data which need to be stored and transferred to satisfy user requests tend to grow over time.

Single or clustered IPS Server

IPS Server is inherently-designed to operate in a clustered architecture with multiple server machines, which requires (at minimum) only a basic load balancer to mediate the client-server traffic.

A cluster is relatively simple to implement for an initial deployment (or to switch from a single server machine at a later date). The key design considerations for using a cluster are:

  • Resilience: 2 or 3 server machines are recommended to ensure continuous availability of the IPS Server.
  • Scalability: one server machine can handle up to 200 concurrent user sessions, however the number of batch jobs also needs to be considered, and the level of use of the Economics application which is the most resource-hungry module in Planning Space.

'SSL offloading' is an optional IPS Server configuration, where the SSL encryption and decryption are handled by the load balancer server, and traffic between the load balancer and the IPS Server machines uses unencrypted HTTP communication.

Multi-tenanted IPS server

Tenants in the IPS Server allow for the creation of independent (isolated) deployments which are separately-managed and store data and user profiles in separate databases.

IPS Server is tenanted by design, and must be initially configured with at least one tenant.

Multiple tenants are recommended for the following purposes:

  • to have a UAT (or 'sandbox') environment for software testing that is independent from the production environment(s);
  • to have different production environments that comply with the security and access requirements of different regulatory regimes;
  • to create archive versions of a production environment;
  • to optimise database size for good application performance.

Client-side architecture: ClickOnce or Installer-based deployment

Planning Space is based on client-server architectures and the main architectural design choice to be made is between:

  • ClickOnce (thick client) deployment: Client user machines connect directly to the IPS Server using application programs based on Microsoft ClickOnce technology; this is also referred to as 'bootstrap deployment';
  • Installer-based deployment: Client user machines connect to an application provisioning service (Citrix being the most-commonly used) in the same data center as the IPS Server, which manages the connections to the IPS Server and SQL Server. The Planning Space client applications are installed and run on an application provisioning server, while the user's machine streams a session that is provided by the application provisioning service.

The choice depends mainly on the network latency and total available bandwidth between the client and server locations. The network requirements for ClickOnce-based deployment are:

  • Latency between client machine and IPS Server less than 150 ms;
  • bandwidth of at least 10 MBits per second.

When looking at network capacities you will need to consider growth requirements for your Planning Space deployment, which will tend to grow not only in terms of number of concurrent users but also in terms of the quantities of data being transported for each concurrent user.


Schematic diagram showing Planning Space client-side architecture and network traffic, for a cluster of IPS Servers (two machines). 'ClickOnce client' users communicate with the IPS Servers via a load balancer. 'Installer-based client' users do not communicate directly with the IPS Servers; the Planning Space 'service' is provisioned by the Application Provisioning servers.

Multiple IPS server deployments

Multiple deployments of Planning Space can be created, where the IPS servers and databases operate independently.

Multiple deployments are most commonly used in the case of operational regimes where data pertaining to one country are required to be stored and processed within the borders of the same country.

However, centralized pool licensing for Planning Space applications can be implemented for any number of deployments by using the license server proxy option in the IPS Manager for each deployment. Hence one IPS server can provide shared global licensing services to a group of deployments, which may be more efficient for the overall use of licenses.